Netware Super Library/Netware Super Library.iso/utility/tsrc29/tsr.doc

Text File | 1989-05-05 | 36KB | 797 lines

                        TSR Utilities Version 2.9
                             Kim Kokkonen
                          TurboPower Software
                               5/4/89

Introduction
------------------------------------------------------------------------------
The TSR Utilities are a collection of programs useful for managing DOS memory,
particularly for managing memory-resident programs, also known as TSR's. TSR
stands for "Terminate and Stay Resident". The most popular use of these
programs is for removing TSR's from memory without rebooting the PC. There are
many other uses, however, especially if you are a software developer.

The TSR Utilities have grown to include 11 programs. Here's a quick overview
of each one:

  MARK     marks a position in memory above which TSR's can be released.
  RELEASE  removes TSR's from memory.
  FMARK    performs the same function as MARK but uses less memory.
  MARKNET  like MARK, but saves a more complete picture of system status.
  RELNET   removes TSR's marked with MARKNET.
  WATCH    a TSR itself, it keeps records of other TSR's.
  DISABLE  disables or reactivates TSR's, leaving them in memory.
  RAMFREE  shows how much RAM memory is available.
  MAPMEM   shows what memory resident programs are loaded.
  DEVICE   shows what device drivers are loaded.
  EATMEM   uses up memory for controlled program testing.

These programs are described in detail in the following sections. If you
haven't used them before, be sure to read the documentation: All of the
programs are command line driven, and unexpected events may occur if you just
start typing the program names at the DOS command line.

The documentation for version 2.8 has been revised substantially. If you're
familiar with previous versions of the TSR Utilities, the most important
change in v2.8 is the addition of MARKNET and RELNET. These new programs allow
marking and releasing the Novell NetWare shell, as well as other "problem
TSR's" that could not be released successfully in previous versions.


MARK, FMARK, and RELEASE
------------------------------------------------------------------------------
MARK.COM and RELEASE.EXE are used to remove TSR's from memory, without
requiring a system reboot. In their simplest form, MARK and RELEASE are used
as follows:

1. Run MARK before installing your TSR(s). This marks the current position in
memory and stores information that RELEASE will later need to restore the
system. A common place to call MARK is in your AUTOEXEC.BAT file.

2. Install whatever TSR's you want, using the normal method for each TSR.

3. To remove those TSR's from memory, run RELEASE. This will release all of
the memory above (and including) the last MARK, and will restore the system to
the state at the time the MARK was made.

There are a number of variations of this simple method. First, MARKs can be
stacked in memory, as shown in the following hypothetical batch file:

    MARK
    TSR1
    MARK
    TSR2
    MARK
    TSR3

Each call to RELEASE releases memory above and including the last MARK. In
this example, the first call to RELEASE would remove TSR3 and the last MARK
from memory, the second call would remove TSR2 and its MARK, and so on.

MARK and RELEASE may be called using a command line parameter. The parameter
specifies a "mark name" and allows releasing TSR's to a specific point in
memory. Consider the following example:

    MARK TSR1
    TSR1
    MARK TSR2
    TSR2
    MARK TSR3
    TSR3

This loads the three TSR's just as in the previous example. However, if
RELEASE were called like this

    RELEASE TSR2

then both TSR2 and TSR3 would be removed from memory. Note that the use of
such a name does not allow just a single layer of TSR's to be removed (just
TSR2, for example). RELEASE always removes all TSR's including and beyond the
one named.

A mark name is any string up to 126 characters long. The name may not include
white space (blanks or tabs). Case (upper or lower) is not significant when
matching mark names.

When named marks are used as in this example, calling RELEASE without
specifying a mark name will still remove the last TSR from memory. Assuming
that TSR1, TSR2, and TSR3 are still in memory, typing just RELEASE would
remove TSR3 and the last mark. It is possible to change this behavior by using
"protected marks", which can be released only by explicitly specifying their
names. A protected mark is placed by giving it a name that starts with an
exclamation point, '!'. Consider the following:

    MARK TSR1
    TSR1
    MARK TSR2
    TSR2
    MARK !TSR3
    TSR3

Here !TSR3 specifies a protected mark. Typing just RELEASE would produce an
error message "No matching marker found, or protected marker encountered". The
same error would occur after entering the command RELEASE TSR2. When this
error occurs, RELEASE does not remove any TSR's from memory.

The only way to remove TSR3 in this case is by entering

    RELEASE !TSR3

Each time a MARK is placed in memory, it consumes about 1600 bytes of RAM
space, which is used to store a copy of the system interrupt vector table and
other information with which RELEASE can later restore the system. Although
1600 bytes isn't very much, we can reduce this memory usage by storing the
information in a disk file rather than in memory. FMARK.COM is a variation on
MARK that does just that. You can call FMARK at any time that you would call
MARK. FMARK uses only about 150 bytes of memory.

All calls to FMARK must include a command line parameter to specify the name
of the file:

    FMARK [d:][directory]filename

You should generally specify a complete pathname for the mark file. When you
later call RELEASE, you must give it the identical pathname, regardless of
what the current directory happens to be at the time. For example, if you
specified the following file mark

    FMARK C:\TEST\TEST.MRK

then the following calls to RELEASE would generate an error:

    RELEASE TEST.MRK
    RELEASE C:TEST.MRK

even if the current directory on drive C: was \TEST. The only way to call
RELEASE is with

    RELEASE C:\TEST\TEST.MRK
or
    release c:\test\test.mrk

RELEASE can use either type of mark: in-memory or on-disk. Note that RELEASE
treats marks placed with FMARK just like protected marks. That is, they can be
released only by explicitly naming them. (This is a change in behavior from
versions of RELEASE prior to 2.8. The change is especially important when net
marks, described below, are also in use.)

Consider the following example:

    MARK
    TSR1
    FMARK C:\MARKS\TSR2.MRK
    TSR2

Typing just RELEASE in this situation generates the warning message "No
matching marker found, or protected marker encountered", because the file mark
is treated like a protected mark.

TSR2 can be removed from memory by entering

    RELEASE C:\MARKS\TSR2.MRK

RELEASE deletes the mark file when it has finished.

RELEASE has several command line options to modify its behavior. The following
table lists the options, which must start with a slash, '/', or a hyphen, '-'.

    /E         do NOT access EMS memory.
    /K         release memory, but keep the mark in place.
    /S chars   stuff string (<16 chars) into keyboard buffer on exit.
    /?         write this help screen.

None of the options is required for normal use of RELEASE.

/E is made available for systems running early, buggy EMS (expanded memory)
drivers that don't correctly implement all of the EMS 3.2 system calls. Don't
use it unless you have an EMS-related problem during or after running RELEASE.

/K is useful when you will be releasing and reloading a TSR repeatedly. With
it, you avoid the need to replace the mark each time the TSR is released.
Using /K in combination with a file mark also prevents RELEASE from deleting
the mark file.

/S followed by at least one space and then a short string (15 characters or
fewer) tells RELEASE to stuff this string into the keyboard buffer just before
exiting. RELEASE automatically adds a carriage return to the end of the
string.

To explain why the /S option is important, we must digress a moment. Let's
assume that you normally keep SideKick loaded, but that you must unload it in
order to have enough memory free to run Lotus 1-2-3. It would seem reasonable
to write a little batch file like this:

   RELEASE SK
   LOTUS
   MARK SK
   SK

which would remove the previously loaded SideKick from memory, run Lotus, and
then load SideKick again. Unfortunately, this won't work!

The reason is complicated to explain. It must suffice here to say that DOS
batch files trap memory, and the memory freed by a call to RELEASE does not
truly become available until the current batch file ends.

Now perhaps the need for the /S option becomes clear. We can split the
previous batch file into two:

  batch1:
    RELEASE SK /S BATCH2

  batch2:
    LOTUS
    MARK SK
    SK

The first batch file releases the memory and stuffs the characters
'BATCH2<Enter>' into the keyboard buffer. When the batch file ends, the
released memory becomes available. DOS automatically reads the keystrokes
waiting in the buffer and starts up the second batch file, which runs Lotus
and later reloads SideKick.

To keep things simple, the /S option pokes the specified keystrokes directly
into the system keyboard buffer. As a result, the number of keystrokes is
limited to 15 (not counting the <Enter> key, which RELEASE adds automatically).
This always allows enough keys to start another batch file, however, and the
new batch file can take over from there.

RELEASE detects when it is releasing memory within a batch file. It writes a
warning message to that effect, but continues processing anyway under the
assumption that the batch file is about to end. You can ignore the warning if
you've already taken account of DOS's memory management behavior within batch
files.

MARK and RELEASE are capable of removing many, but not all, TSR's from memory.
The TSR's that cannot be released fall into two categories: those that cannot
be released without specific internal knowledge of the TSR, and those that can
be released by storing additional general information about the system.

The most common examples of TSR's that we can't be released without internal
knowledge are those that cooperate with other TSR's in memory. Examples
include Microsoft's MOUSE driver and its associated MENU program; and the
program CED with its "user-installed commands" such as KEYIN, HS, RAW, and
others. These programs can be released, but only if all the cooperating
partners are released at the same time. CED is well-behaved in that it
provides a built-in command (KILL) to release its partners. MOUSE is not so
flexible, though.

Other TSR's modify well-defined areas of DOS memory that MARK and FMARK simply
don't record. Examples of such TSR's include the Novell NetWare workstation
shell and certain DOS utilities like MODE and SHARE. To deal with these
programs we've written the MARKNET and RELNET utilities, described in the next
section, which store just about every imaginable DOS data area, including some
that are undocumented by MicroSoft. If you have trouble removing a particular
TSR with MARK/RELEASE, try using MARKNET/RELNET instead.

WARNING: you should not use either RELEASE or RELNET to try to release most
disk caching programs. If you do so, part of the information that should be
stored on disk will never make it, and you may end up with a corrupted disk
as a result. If you know that the disk cache uses a "write-through" algorithm
(which guarantees that all writes immediately go to disk), or if the disk
cache has a "flush the cache" command, then it may be safe to release the
cache.

WARNING: you cannot release the DOS 3.3 FASTOPEN or APPEND TSR's. These TSR's
patch internal DOS data areas that cannot be reliably located by even MARKNET
and RELNET.


MARKNET and RELNET
------------------------------------------------------------------------------
Use of these utilities is very similar to that described in the preceding
section. MARKNET is analogous to FMARK, and RELNET is like RELEASE. Because
MARKNET stores so much information about the system, it writes it to a disk
file in order to reduce its own memory usage. Command line syntax for MARKNET
and RELNET is:

  MARKNET [d:][directory]filename
  RELNET  [d:][directory]filename [options]

The main command line parameter to each program specifies the name of the file
where the mark information will be stored. We refer to this file as the net
mark file. A complete pathname should be specified for the net mark file.
RELNET's pathname must exactly match that passed to MARKNET, with the
exception of case.

Note that MARKNET and RELNET may be used in almost any situation where FMARK
and RELEASE are used. MARKNET saves all of the same system information as does
FMARK, but it goes further to store information such as the device driver
chain, DOS internal variable areas, DOS system file tables, DOS environment,
communications port status, and other information. Nevertheless, MARKNET and
RELNET were written primarily because of the large demand to release the
NetWare shell. We'll refer to NetWare specifically in the following and
provide an example of how to load and release it.

The only new restriction for using MARKNET is that the system must be running
DOS version 3.0 or later. MARKNET depends on the format of certain internal
DOS data structures that were quite different in DOS version 2.

Like FMARK, MARKNET leaves a small (144-192) byte mark in memory, and writes a
disk file to store the system status. MARKNET's file varies in size, but is
typically 3-4K bytes. The size depends on the number of device drivers, the
value of the 'FILES=' directive in CONFIG.SYS, and other implementation
details of DOS.

Do not attempt to redirect the output of MARKNET. Doing so will waste at least
one file handle that cannot be recovered later by RELNET.

Marks placed with MARK, FMARK, and MARKNET may be mixed in the same system.
RELEASE treats all marks placed with MARKNET as protected; such marks may be
released only by calling RELNET explicitly. Consider the following example:

  MARK
  TSR1
  FMARK C:\MARKS\TSR2.MRK
  TSR2
  MARKNET C:\MARKS\TSR3.MRK
  TSR3

Entering RELEASE by itself would generate a warning and do nothing else.
Entering RELEASE C:\MARKS\TSR2.MRK would generate the same warning. The only
way to get all three of these TSR's out of memory would be to enter the
following commands in sequence:

  RELNET C:\MARKS\TSR3.MRK
  RELEASE C:\MARKS\TSR2.MRK
  RELEASE

RELNET has options to control how much of the system state it restores.
Several of the options match those of RELEASE; new ones are needed because of
the additional information that MARKNET stores. RELNET accepts the following
options:

  /C        do NOT restore the communications ports.
  /E        do NOT access EMS memory.
  /K        release memory, but keep the mark in place.
  /P        do NOT restore DOS environment.
  /R        revector 8259 interrupt controller to powerup state.
  /S chars  stuff string (<16 chars) into keyboard buffer on exit.
  /T        do NOT reset the system timer chip.
  /V        verbose: show each step of the restore.
  /?        write help screen.

None of these options is required in order to release the NetWare workstation
shell.

/C keeps RELNET from restoring the communications state of the system (as
encoded in the 8250 async chip and the 8259 programmable interrupt
controller). Because both of these chips provide readable registers, MARKNET
is able to store an accurate picture of the communications state when the mark
is stored; RELNET can restore the state to exactly what it was. Therefore, the
/C option should be needed rarely, perhaps only on newer PS/2 models that
don't use the 8250 as a communications controller. (We haven't tested MARKNET
and RELNET on a PS/2 model 50z. Use caution if you have such a system.) Note
that MARKNET stores information only about COM1 and COM2.

/E is made available for systems running early, buggy EMS drivers that don't
correctly implement all of the EMS 3.2 system calls. Don't use it unless you
have an EMS-related problem during or after running RELNET.

/K is useful when you will be releasing and reloading a TSR repeatedly. With
it, you avoid the need to replace the mark each time the TSR is released.
Using /K prevents RELNET from deleting the net mark file.

/P keeps RELNET from restoring the DOS environment, which it normally does
because NetWare modifies the DOS PATH. In some cases, other changes to the
environment should not be undone; use the /P switch only when such changes
must be preserved.

/R may be useful for unloading task-switching utilities that "revector" the
hardware interrupt controller. Use it only if it solves a problem.

/S followed by at least one space and then a short string (15 characters or
fewer) tells RELNET to stuff this string into the keyboard buffer just before
exiting. RELNET automatically adds a carriage return to the end of the string.
See the discussion of /S in the preceding section for more details.

/T keeps RELNET from resetting the system timer chip to its default rate,
which it does by default.

/V activates additional status reporting during the release and may provide
useful information in cases when RELNET isn't working.

The following is a simplified version of a NetWare LOGIN.BAT file with support
for releasing the shell:

  rem place the mark
      marknet C:\NET\NETWARE.MRK

  rem load the NetWare shell TSR's
      ipx
      net3
  rem optional portions of the shell
  rem netbios
  rem int2f

  rem switch to login drive and log in
      F:
      login USERNAME

The items in uppercase, at least, will need to be customized for a given user
and workstation.

NetWare could then be released with the following batch file:

  rem let the server know we're leaving
      z:\public\logout
  rem restore the workstation
      relnet C:\NET\NETWARE.MRK


WATCH and DISABLE
------------------------------------------------------------------------------
WATCH.COM is a resident program that keeps track of other memory resident
programs. As a TSR goes resident, WATCH updates a data area in memory that
contains information about what interrupt vectors were taken over. This
information can later be used by MAPMEM and DISABLE to show more details about
interrupts than normally available.

Installation of WATCH.COM is optional. All of the TSR Utilities except DISABLE
can be used whether or not WATCH is installed.

If you want to use it, WATCH.COM should be installed as the first TSR in your
AUTOEXEC.BAT file. WATCH uses about 4000 bytes of memory when it is installed.
Most of this memory holds various information about the TSR's installed in the
system -- it includes two copies of the interrupt vector table, and a data
area containing a list of the interrupt vectors taken over by each TSR. This
information is used by DISABLE to deactivate and reactivate TSR's without
removing them from memory.

With DISABLE.EXE, you can disable and reenable specified memory resident
programs without removing them from memory. Its function is analogous to that
performed by REFEREE from Persoft, although DISABLE has neither a fancy user
interface nor an option to work from within other programs. DISABLE can allow
conflicting TSR's to coexist, and it can let you run applications whose
keystrokes conflict with those of TSR's already loaded. DISABLE also provides
a small bonus in that it can be used to detect the presence of a particular
TSR in memory, thus allowing the design of semi-intelligent batch files.

In order to use DISABLE, you must install WATCH.COM as the first memory
resident program in your system. WATCH keeps the detailed information about
each memory resident program that DISABLE uses to later control them.

Like the other TSR Utilities, DISABLE is operated from the command line. You
specify a single TSR by its name (if you are running DOS 3.0 or later) or by
its address as determined from a MAPMEM report (described below). If you
specify an address, immediately precede the address with a dollar sign "$" and
specify the address in hexadecimal.

The name specified for a TSR is the one reported by MAPMEM in the "owner"
column. If the owner column reports "N/A", then you must instead specify the
address from the "PSP" column.

DISABLE accepts the following command line syntax:

  DISABLE TSRname|$PSPaddress [options]

Options may be preceded by either / or -. Valid options
are as follows:

     /A     reactivate the specified TSR.
     /C     check for the presence of the specified TSR.
     /?     write a help screen.

If no option is specified, DISABLE will disable the named TSR.

Examples of usage:

  DISABLE SK              disables SideKick
  DISABLE SK /A           reenables SideKick
  DISABLE SK /C           checks for the presence of SideKick
  DISABLE $2F2E           disables the TSR at address 2F2E (hex)

DISABLE sets the DOS ERRORLEVEL in order to return status information to a
batch file. It uses the following values of errorlevel:

  0       success: TSR is present, was disabled, or was reenabled.
  1       TSR is present, but no action was required to enable or disable it.
  2       TSR is not present in memory.
  254     invalid command line.
  255     severe error.

WARNING: you cannot use DISABLE to deactivate SideKick Plus, whose swapping
technique is incompatible with DISABLE.


MAPMEM, RAMFREE, and DEVICE
------------------------------------------------------------------------------
These three utilities provide status information about DOS memory usage. They
don't make active changes to the system like RELEASE and DISABLE do.

MAPMEM.EXE displays a map of DOS memory. It shows the resident programs, how
much memory they use, and what interrupt vectors each one controls. MAPMEM
also shows information about expanded and extended memory when available.

MAPMEM writes to the standard output -- hence, the output can be printed or
stored to a file by using DOS redirection.

Here is an example of MAPMEM output:

 PSP  blks bytes owner    command line        chained vectors
----- ---- ----- -------- ------------------- ------------------------------
0008   1   34240 config
1228   2    3536 command
1315   2    3888 WATCH    TSR WATCHER         16 21 27
140A   2   22128 CED      N/A                 1B 21 64
1973   1     144 N/A      C:\MARK\PS.MRK
197D   2     736 PSKEY    S3                  09 15
19AD   2   68400 PS       /B:0 /E:1 /R:0 /... 01 03 06 0D
2A62   2    1504 MARK     test                00 3F
2AC2   2   10384 EATMEM   10
2D4D   2  469808 free

block   bytes   (Expanded Memory)
-----   ------
    1  1048576
 free  1048576
total  2097152
                (Extended Memory)
total   379240

"PSP" stands for Program Segment Prefix. This is the physical address,
specified in hexadecimal, where the program was loaded. If you're running DOS
2.x, you'll need to use an address from this column to pass to DISABLE.

"Blks" is the number of memory blocks DOS is using to manage the program. This
will typically be two: one for the program itself and another for the
environment that stores the program name, the DOS path, and other environment
variables.

"Bytes" is the number of bytes of memory, specified in decimal, allocated to
the program.

The "owner" column shows the name of the program that allocated the block. An
"N/A" in this column means either that the program deallocated its environment
to reduce memory usage (as shown on the fifth row of the report) or that the
system is running DOS 2.x, where the owner names are simply not available.

"Command line" shows the command line entered when the TSR was originally
loaded. Some TSR's overwrite their command line with other code or data in
order to save memory space. MAPMEM can usually detect this behavior and will
display "N/A" in the command line column when it does.

The last column will be titled with either "chained vectors" or "hooked
vectors". When WATCH is loaded, "chained" will appear; otherwise, "hooked"
will. The numbers in this column indicate what interrupt vectors the TSR has
grabbed. Without WATCH, MAPMEM must use a heuristic technique to identify
the owner of each vector; don't be surprised if you see some ridiculous
looking vector numbers. With WATCH, MAPMEM should report an accurate list for
each TSR, and should show the complete chain of control for each interrupt.

MAPMEM indicates disabled TSR's by displaying the word "disabled" in the
interrupt vector column of the report.

The expanded memory report shows each allocated block of expanded memory, as
well as the free and total EMS space. When extended memory is available,
MAPMEM shows just the total amount available. The extended memory report is
not highly reliable because of the lack of a standardized method for
allocating extended memory space. Some applications that use extended memory
allocate the space by making it appear that the memory is no longer in the
system.

MAPMEM shows the various types of marks so that you can examine them prior to
a releasing them. As shown in the example, MAPMEM reports a call to MARK with
the owner name "MARK", and the mark name (if any) in the command line area.
The result of a call to FMARK or MARKNET will show "N/A" in the owner column
(due to the minimal memory kept by an FMARK), and the name of the mark file in
the command line area.

MAPMEM offers the following command line options:

     /V     verbose report.
     /?     write a help screen.

The verbose report shows each individual memory block rather than just one for
each program. It also adds two new columns of information. "Mcb" stands for
Memory Control Block. This is a physical address, expressed in hexadecimal,
of the DOS data structure used for managing each block of memory. The MCB
address is typically one less than the address of the program. "Files" reports
the number of files kept open by the TSR. In most cases this will be zero.
When it is non-zero, the maximum number of files opened by the rest of the
programs (including the foreground application) is reduced accordingly.

RAMFREE.COM is a tiny program with a single purpose: to tell you how many
bytes of memory are free for the next application. The number it reports is
the same as that reported by the DOS CHKDSK utility. RAMFREE's advantage is
that you don't need to wait for your hard disk to be analyzed before you find
out how much memory is free.

DEVICE.EXE reports on device drivers installed by the CONFIG.SYS file. It
shows the memory used by DOS itself, any additional drivers installed in
CONFIG.SYS, and the space used for DOS file handles and buffers. Here is a
simple example of DEVICE output:

 Address     Bytes   Name           Hooked vectors
---------   ------   -------------- --------------
0070:0BB3        -   CON
0070:0C68        -   AUX
0070:0C7A        -   COM1
0070:0D17        -   PRN
0070:0D29        -   LPT1
0070:0E15        -   CLOCK$
0070:0EE5        -   3 Block Units
0070:2071        -   LPT2
0070:2083        -   LPT3
0070:2095        -   COM2
0000:2C58    37712   NUL            08 0A 0C 0D 0E 13 25 26 29 31 70 72
                                    73 74 75 76 77
09A5:0000     3488   0 Block Units
0A7F:0000       18   EMMXXXX0
0A7F:0012       46   386MAX$$       20
0A83:0000      768   1 Block Unit   19
0AB3:0000      768   1 Block Unit
0AE3:0000    18256   DOS buffers

The devices up to and including NUL are all part of DOS. DEVICE lumps their
memory usage into a single value next to the NUL device. The memory usage
associated with NUL does not include the interrupt vector table, the BIOS data
area, or the low-memory DOS data area. If you wish to add this memory to the
total, just take the hexadecimal segment of the first driver you see (in this
case CON) and multiply it by 16 decimal. When the segment is 0070 as shown,
that adds 1792 bytes to the total space for DOS.

Don't expect the sum of the DEVICE bytes to match the bytes reported by MAPMEM
in the row labeled 'config'. MAPMEM's report shows what DOS thinks has been
allocated, but that number isn't complete since some of the memory was used
before DOS was truly loaded. However, you should find that the sum of the
DEVICE bytes, plus all of MAPMEM's memory excluding the 'config' row, equals
the total normal RAM in the system.

DEVICE also lumps all of the drivers up to NUL into a single block when it
comes to reporting hooked interrupt vectors. Because WATCH can't be installed
prior to these device drivers, DEVICE must use an empirical technique to
detect which vectors each driver controls. Therefore, some meaningless vectors
may appear in the list. Any vectors that are grabbed by another program after
the driver is loaded will not appear.

"Block units" typically refer to disk drives. Any drivers that appear after
the NUL device are in the order that you've entered them in CONFIG.SYS.
Drivers loaded for non-standard hard disks, like SpeedStor, sometimes make odd
entries in the DEVICE report, as shown with "0 Block Units" above. RAM disks
appear more logically: each of the "1 Block Unit" entries above is a VDISK
with the data stored in extended memory.

Devices like 386MAX may also cause odd-looking entries: 386MAX puts most of
its code in extended memory, and leaves just a bit behind in normal memory.

DEVICE offers the following command line options:

     /R     raw report.
     /?     write a help screen.

The raw report shows more information about the device drivers, but in a less
convenient format. Here's an example, taken on the same system as the previous
report.

 Starting      Next             Strategy   Interrupt   Device
 Address     Hdr Addr   Attr   Entry Pnt   Entry Pnt   Name
---------   ---------   ----   ---------   ---------   --------
0000:2C58   0AB3:0000   8004   0000:14C6   0000:14CC   NUL
0AB3:0000   0A83:0000   0800   0000:00A9   0000:00D4   1 Block Unit
0A83:0000   0A7F:0012   0800   0000:00A9   0000:00D4   1 Block Unit
0A7F:0012   0A7F:0000   C000   0000:0036   0000:003B   386MAX$$
0A7F:0000   09A5:0000   8000   0000:0036   0000:003B   EMMXXXX0
09A5:0000   0070:0BB3   2000   0000:0012   0000:001D   0 Block Units
0070:0BB3   0070:0C68   8013   0000:00C6   0000:00D1   CON
0070:0C68   0070:0D17   8000   0000:00C6   0000:00D7   AUX
0070:0D17   0070:0E15   A040   0000:00C6   0000:00E6   PRN
0070:0E15   0070:0EE5   8008   0000:00C6   0000:010C   CLOCK$
0070:0EE5   0070:0C7A   0840   0000:00C6   0000:0112   3 Block Units
0070:0C7A   0070:0D29   8000   0000:00C6   0000:00D7   COM1
0070:0D29   0070:2071   A040   0000:00C6   0000:00EC   LPT1
0070:2071   0070:2083   A040   0000:00C6   0000:00F4   LPT2
0070:2083   0070:2095   A040   0000:00C6   0000:00FC   LPT3
0070:2095   0070:FFFF   8000   0000:00C6   0000:00DD   COM2

In this report, the drivers are listed in DOS priority order rather than the
order in which they are loaded in memory. Additional columns describe how DOS
treats each driver. Ray Duncan's book "Advanced MS-DOS" is a good place to
learn more about these details.

The DEVICE program assumes that all device drivers are loaded in the
CONFIG.SYS file. That is not the case with the NetWare shell, which patches
itself into the device driver chain. DEVICE will write a warning message and
terminate before reporting the first patched-in driver. The raw device report
will still show all of the devices even in this case.


EATMEM
------------------------------------------------------------------------------
EATMEM is a small program that is useful only to software developers. It is a
TSR that consumes a specified amount of memory. Developers can use it to
simulate a system with less memory, or to create a buffer zone between an
application and programs preceding it.

The memory used by EATMEM can be freed only by using MARK and RELEASE. Call
EATMEM with a single command line parameter, specifying the (decimal) number
of KILOBYTES to eat up:

  EATMEM KiloBytesToEat

EATMEM will allow you to eat up all available memory, leading to a system
crash when COMMAND.COM cannot be reloaded. Be sure to calculate how much
memory to use before calling EATMEM.


Version History
------------------------------------------------------------------------------
If you're converting to this version from version 2.5 or earlier, be sure to
delete RELEASE.COM, DISABLE.COM, and MAPMEM.COM from your directories. The new
versions are EXE files instead of COM files.

See the source code for the programs for more detailed information about
changes.

Version 2.9  5/4/89
  MAPMEM - fix problem when EMS is available but none is allocated
  DISABLE - fix problem when TSR to disable is last one loaded
          - disallow disable when patches would overlap (SK+)
          - add /O option to allow disable even for overlap (Periscope)
  RELEASE/RELNET - don't treat file marks as protected marks

Version 2.8  3/10/89
  add MARKNET/RELNET
  add DEVICE
  add extended memory reporting to MAPMEM
  add TSR detection capability to DISABLE
  treat file and net marks as protected in RELEASE
  add key stuffing routine to RELEASE
  remove 8259 revector routine from RELEASE (available in RELNET)

Version 2.7  3/4/89
  used for limited testing of MARKNET/RELNET

Version 2.6  1/15/89
  fix problem in MARK/RELEASE when command processor is EXE file
  convert source to Turbo Pascal 5.0

Version 2.5  6/2/87
  version checks to avoid mixing different MARK/RELEASE

Version 1.0  1/2/86
  initial version

For information about other versions, see the source files.


Copyright and License Information
------------------------------------------------------------------------------
The TSR Utilities are copyright (c) 1986,1987,1989 by Kim Kokkonen. All Rights
Reserved.

These programs are copyrighted, but license is hereby granted to distribute
them for personal, non-commercial use. You may use them yourself, give them to
your friends or co-workers, or distribute them for a cost-based fee ($10 or
less) as part of a user's group or bulletin board service. If you wish to
distribute these programs as part of a commercial package, please contact us
for a license agreement.

These programs are not shareware: we're not asking for a donation. However, if
you request that we send you a new version, we'll ask for $20 to cover our
time and costs. The disk will include the latest version of the TSR Utilities,
including the complete source code.

The first (and only) place that we upload new versions of the TSR Utilities is
on CompuServe, the BPROGA forum, in the latest Turbo Pascal library, which at
this time is LIB 2. The executable programs are stored in a file called
TSRCOM.ARC, and the source code is stored in a file called TSRSRC.ARC. From
CompuServe, the programs fan out to public domain bulletin boards around the
world. Unfortunately, due to the transient nature of bulletin boards, we
cannot recommend where besides CompuServe you should call to download the
latest version.

The TSR Utilities were written by Kim Kokkonen, with thanks to Neil Rubenking
for the original idea behind MARK and RELEASE. Special thanks to Richard
Wilson and Barry Simon at CalTech for the idea that lead to FMARK, and for
much useful correspondence about the TSR Utilities.

You can reach Kim Kokkonen at:

     TurboPower Software
     P.O. Box 66747
     Scotts Valley, CA 95066-0747

     408-438-8608 (voice only, Monday-Friday 9AM-5PM)
     Compuserve: 72457,2131